Internet Engineering Task Force (IETF) M. Boucadair 


Request for Comments: 7371 France Telecom 
Updates: 3306, 3956, 4291 S. Venaas 
Category: Standards Track Cisco 
ISSN: 2070-1721 September 2014 


Updates to the IPv6 Multicast Addressing Architecture 


Abstract 
This document updates the IPv6 multicast addressing architecture by 
redefining the reserved bits as generic flag bits. The document also 
provides some clarifications related to the use of these flag bits. 
This document updates RFCs 3956, 3306, and 4291. 

Status of This Memo 


This is an Internet Standards Track document. 


This document is a product of the Internet Engineering Task Force 


(IETF). It represents the consensus of the IETF community. It has 
received public review and has been approved for publication by the 
Internet Engineering Steering Group (IESG). Further information on 


Internet Standards is available in Section 2 of RFC 5741. 
Information about the current status of this document, any errata, 


and how to provide feedback on it may be obtained at 
http://www.rfc-editor.org/info/rfc7371. 
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Les 


dn, 


Introduction 


This document updates the IPv6 addressing architecture [RFC4291] by 
redefining reserved bits as generic flag bits (Section 2). The 
document also provides some clarifications related to the use of 
these flag bits (Section 3). 


This document updates [RFC3956], [RFC3306], and [RFC4291]. These 
updates are logical consequences of the new processing rules in 
Section 3. 


Textual representation of IPv6 addresses included in the RFC updates 
follows the recommendation in [RFC5952]. 


1. Requirements Language 


The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", “SHALL NOT", 
"SHOULD", “SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 
document are to be interpreted as described in RFC 2119 [RFC2119]. 


Addressing Architecture Update 


Bits 17-20 of a multicast address, where bit 1 is the most 
Significant bit, are defined in [RFC3956] and [RFC3306] as reserved 
bits. This document defines these bits as generic flag bits so that 
they apply to any multicast address. These bits are referred to as 
"ff2" (flag field 2), while the "flgs" bits in [RFC4291] [RFC3956] 
are renamed to "ff1" (flag field 1). 


Within this document, flag bits denote both ffl and ff2. 


Defining the bits 17-20 as flags for all IPv6 multicast addresses 
allows addresses to be treated in a more uniform and generic way, and 
allows for these bits to be defined in the future for different 
purposes, irrespective of the specific type of multicast address. 

For the record, this design choice was initially triggered by the 
specification in [ADDR-FORMAT], which proposed associating a meaning 
with one of the reserved bits. Moreover, [ADDR-FORMAT] also 
considered the use of the last remaining flag in ffl, but that 
approach was abandoned because it is not clear at this stage whether 
there are other usage scenarios of the flag. 


Section 4 specifies the updated structure of the addressing 
architecture. 


Further specification documents may define a meaning for these 
flag bits. 
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3. Flag Bits: New Processing Rules 


Some implementations and specification documents do not treat the 
flag bits as separate bits but tend to use their combined value as a 
4-bit integer. This practice is a hurdle for assigning a meaning to 
the remaining flag bits. Below are listed some examples for 
illustration purposes: 


o The reading of [RFC3306] may lead one to conclude that ff3x::/32 


is the only allowed Source-Specific Multicast (SSM) IPv6 prefix 
block. 


o [RFC3956] states that only ff70::/12 applies to Embedded-RP. 


Particularly, implementations should not treat the fff0::/12 range 
as Embedded-RP. 


To avoid such confusion and to unambiguously associate a meaning with 
the remaining flags, the following requirement is made: 


Implementations MUST treat flag bits as separate bits. 
4. RFC Updates 
4.1. Updates to RFC 3306 
4.1.1. Update #1 


This document changes Section 4 of [RFC3306] as follows: 


OLD: 
be oge. (Oe en |; |: S| 64 | 32 | 
FAE tonsa sata 555 to----- 7 toasts to-- 57-7 + 
|11111111|f£lgs|scop| reserved | plen | network prefix | group ID | 
phrin prnh aH | a : saan an aa ea Frinn + 
+-+-+-+-+ 
flgs is a set of 4 flags: |o|o|P|t| 
+-+-+-+-+ 
o P = 0 indicates a multicast address that is not assigned 


based on the network prefix. This indicates a multicast 
address as defined in [ADDRARCH]. 


o P = 1 indicates a multicast address that is assigned based 
on the network prefix. 
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o If P = 1, T MUST be set to 1, otherwise the setting of the T 
bit is defined in Section 2.7 of [ADDRARCH]. 
The reserved field MUST be zero. 


Note: [ADDRARCH] is a reference listed in [RFC3306]. [ADDRARCH ] 
has been since obsoleted by [RFC4291]. 


NEW 
Ji) og ob pa [hai a a 64 |o 32. | 
+------—- +----+----+----+----+-------- 4+---------------- +---------- + 
|11111111|ff1 |scop|ff2 |rsvd| plen | network prefix | group ID | 
+-------- +----+----+----+----+-------- 4+---------------- +---------- + 
+-+-+-+-+ 
ff1 (flag field 1) is a set of 4 flags: |x|y|P|T| 
+—+-+-4+-+ 
X and Y may each be set to 0 or 1. Note that X is for future 
assignment, while a meaning is associated with Y in RFC 3956. 

o P = 0 indicates a multicast address that is not assigned 
based on the network prefix. This indicates a multicast 
address as defined in [RFC4291]. 

o P = 1 indicates a multicast address that is assigned based 


on the network prefix. 

o If P = 1, T MUST be set to 1; otherwise, the setting of the 

T bit is defined in Section 2.7 of [RFC4291]. 
+-+-+-+-+ 
ff2 (flag field 2) is a set of 4 flags: |r|r|rlr| 
+-+-+-+-+ 
where "rrrr" are for future assignment as additional flag bits. 
r bits MUST each be sent as zero and MUST be ignored on receipt. 


Flag bits denote both ffl and ff2. 
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4.1.2. Update #2 


This document changes Section 6 of [RFC3306] as follows: 
OLD: 


These settings create an SSM range of FF3x::/32 (where ’x’ is any 


valid scope value). The source address field in the IPv6é header 
identifies the owner of the multicast address. 


NEW: 
If the flag bits in ffl are set to 0011, these settings create an 
SSM range of ff3x::/32 (where ’x’ is any valid scope value). The 
source address field in the IPv6 header identifies the owner of 
the multicast address. ff3x::/32 is not the only allowed SSM 


prefix range. For example, if the most significant flag bit in 
ffl is set, then we would get the SSM range ffbx::/32. 


4.2. Updates to RFC 3956 


4.2.1. Update #1 


This document changes Section 2 of [RFC3956] as follows: 


OLD: 


As described in [RFC3306], the multicast address format is 
as follows: 


Where flgs are "0011". (The first two bits are as yet undefined, 
sent as zero and ignored on receipt.) 
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NEW: 


The multicast address format is as follows: 


| 8 fips ASO ae fin, Ae lly A ee. hi 64 | 32 | 

4+-------- 4+----4----4----+4----+----4---------------- 4+---------- + 

|11111111|£ff1 |scop| f£2 | rsvd|plen | network prefix | group ID | 

4+-------- 4----4----4----+4----+----4---------------- 4+---------- + 
+-+-+-+-+ 

ff1 (flag field 1) is a set of four flags: |x|R|P|TI 
+-+-+4+-4+-+ 


where X is for future assignment as an additional flag bit. 
X may be set to 0 or 1. 


+-+-+4+-4+-+ 
ff2 (flag field 2) is a set of 4 flags: |r|r|rlr| 
+-+-+-+-+ 


where "rrrr" are for future assignment as additional flag bits. 
r bits MUST each be sent as zero and MUST be ignored 
on receipt. 
Flag bits denote both ffl and ff2. 
4.2.2. Update #2 


This document changes Section 3 of [RFC3956] as follows: 


OLD: 
| 8 L-ap ARG) es alice. 64 | 32 
4+-------- 4+----+----4----+4----4----4---------------- 4+---------- + 
|11111111|f£1lgs|scop|rsvd|RIID|plen| network prefix | group ID | 
4+-------- 4+----+----4----+4----4----4---------------- 4+---------- + 
+-+-+-+-+ 
flgs is a set of four flags: |o|R|P|T| 
+-+-+-+-+ 


When the highest-order bit is 0, R = 1 indicates a multicast address 
that embeds the address on the RP. Then P MUST be set to 1, and 
consequently T MUST be set to 1, as specified in [RFC3306]. In 
effect, this implies the prefix FF70::/12. In this case, the last 4 
bits of the previously reserved field are interpreted as embedding 
the RP interface ID, as specified in this memo. 
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The behavior is unspecified if P or T is not set to 1, as then the 
prefix would not be FF70::/12. Likewise, the encoding and the 
protocol mode used when the two high-order bits in "flgs" are set to 
11 ("FFFO::/12") is intentionally unspecified until such time that 
the highest-order bit is defined. Without further IETF 
specification, implementations SHOULD NOT treat the FFFO::/12 range 
as Embedded-RP. 


NEW: 
| 8 | 4] 4| 4| 4ļ|8 | 64 | 32 | 
4+-------- 4+----4----4----+----+----4---------------- 4+---------- + 
|11111111|f£f1 |scop|ff2 |RIID|plen| network prefix | group ID | 
4+-------- 4+----4----+4----+----+----4---------------- 4+---------- + 
+-+-+-+-+ 
ffl is a set of four flags: |x|R|P|T| 
+-+-+4+-4+-+ 


where X is for future assignment as an additional flag bit. 
X may be set to 0 or 1. 


R = 1 indicates a multicast address that embeds the address of the 
RP. Then, P MUST be set to 1, and consequently T MUST be set 
to 1, according to [RFC3306], as this is a special case of 
unicast-prefix-based addresses. This implies that, for instance, 
prefixes f£70::/12 and fff0::/12 are embedded RP prefixes. When 
the R-bit is set, the last 4 bits of the field that were reserved 
in [RFC3306] are interpreted as embedding the RP interface ID, as 
specified in this memo. 
4.2.3. Update #3 
This document changes Section 4 of [RFC3956] as follows: 
OLD: 


o It MUST be a multicast address with "flgs" set to 0111, that is, to 
be of the prefix FF70::/12, 


NEW: 
o It MUST be a multicast address with the R-bit set to l. 


o It MUST have the P-bit and T-bit both set to 1 when using the 
embedding in this document as it is a prefix-—based address. 
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4.2.4. Update #4 

This document changes Section 7.1 of [RFC3956] as follows: 

OLD: 
To avoid loops and inconsistencies, for addresses in the range 
FF70::/12, the Embedded-RP mapping MUST be considered the longest 
possible match and higher priority than any other mechanism. 

NEW: 
To avoid loops and inconsistencies, for addresses with the R-bit 


set to 1, the Embedded-RP mapping MUST be considered the longest 
possible match and higher priority than any other mechanism. 


5. Security Considerations 


The same security considerations as those discussed in [RFC3956], 
[RFC3306], and [RFC4291] are to be taken into account. 


6. Acknowledgements 


Special thanks to Brian Haberman for the discussions prior to the 
publication of this document. 


Many thanks to Jouni Korhonen, Tatuya Jinmei, Charlie Kaufman, and 
Ben Campbell for their review. 


7. References 
7.1. Normative References 


[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 
Requirement Levels", BCP 14, RFC 2119, March 1997. 


[RFC3306] Haberman, B. and D. Thaler, "Unicast-Prefix—based IPv6 
Multicast Addresses", RFC 3306, August 2002. 


[RFC3956] Savola, P. and B. Haberman, "Embedding the Rendezvous 
Point (RP) Address in an IPv6 Multicast Address", 
RFC 3956, November 2004. 


[RFC4291] Hinden, R. and S. Deering, "IP Version 6 Addressing 
Architecture", RFC 4291, February 2006. 


[RFC5952] Kawamura, S. and M. Kawashima, "A Recommendation for IPv6 
Address Text Representation", RFC 5952, August 2010. 


Boucadair & Venaas Standards Track [Page 9] 


RFC 7371 Multicast Flag Bits September 2014 


TB Informative References 


[ADDR-FORMAT ] 
Boucadair, M., Qin, J., Lee, Y., Venaas, S., Li, X 
M. Xu, "IPv6 Multicast Address With Embedded IPv4 
Multicast Address", Work in Progress, April 2013. 


-, and 


Authors’ Addresses 
Mohamed Boucadair 
France Telecom 
Rennes 35000 
France 
EMail: mohamed.boucadair@orange.com 
Stig Venaas 
Cisco 


USA 


EMail: stig@cisco.com 


Boucadair & Venaas Standards Track [Page 10] 


